Hi all,
The experimental Trending Service[1] will be sunset on December 14th, 2017.
We initially deployed this service to evaluate some real time features in the mobile apps centered on delivering more timely information to users. After some research [2], we found that it did not perform well with users in that use case.
At this point there are no further plans to integrate the service into our products and so we are going to sunset the service to reduce the maintenance burden for some of our teams.
We are going to do this more quickly than we would for a full stable production API as the usage of the end point is extremely low and mostly from our own internal projects. If you this adversely affects any of your work or you have any other concerns, please let the myself or the Reading Infrastructure team know.
Thanks to all the teams involved with developing, deploying, researching and maintaining this service.
P.S. This service was based off of prototypes Jon Robson had developed for detecting trending articles. He will be continuing his work in this area. I encourage you to reach out to him if you were interested in this project.
[1] https://en.wikipedia.org/api/rest_v1/#!/Feed/trendingEdits [2] https://meta.wikimedia.org/wiki/Research:Comparing_most_read_and_trending_ed...
Just a reminder that this is happening this Thursday. Please update any tools you have before then. Thanks!
On Fri, Dec 1, 2017 at 3:30 PM Corey Floyd cfloyd@wikimedia.org wrote:
Hi all,
The experimental Trending Service[1] will be sunset on December 14th, 2017.
We initially deployed this service to evaluate some real time features in the mobile apps centered on delivering more timely information to users. After some research [2], we found that it did not perform well with users in that use case.
At this point there are no further plans to integrate the service into our products and so we are going to sunset the service to reduce the maintenance burden for some of our teams.
We are going to do this more quickly than we would for a full stable production API as the usage of the end point is extremely low and mostly from our own internal projects. If you this adversely affects any of your work or you have any other concerns, please let the myself or the Reading Infrastructure team know.
Thanks to all the teams involved with developing, deploying, researching and maintaining this service.
P.S. This service was based off of prototypes Jon Robson had developed for detecting trending articles. He will be continuing his work in this area. I encourage you to reach out to him if you were interested in this project.
[1] https://en.wikipedia.org/api/rest_v1/#!/Feed/trendingEdits [2] https://meta.wikimedia.org/wiki/Research:Comparing_most_read_and_trending_ed...
-- Corey Floyd Engineering Manager Readers Wikimedia Foundation cfloyd@wikimedia.org
One interesting thing that I noticed about the trending edits API is that it was fairly useful in identifying articles that were under attack by vandals or experiencing an edit war. A lot of times a vandal will just sit on an article and keep reverting back to the vandalized version until an admin shows up, which can sometimes take a while. If you tweak the parameters passed to the API, you can almost get it to show nothing but edit wars (high number of edits, low number of editors).
This makes me think that this API is actually useful, it's just targeted to the wrong use case. If we built something similar, but that just looked for high numbers of revert/undos (rather than edits), and combined it with something like Jon Robson's trending edits user script ( https://en.wikipedia.org/wiki/User:Jdlrobson/Gadget-trending-edits.js), we could create a really powerful tool for Wikipedia administrators to identify problems without having to wait for them to be reported at AN/I or AIV.
On Tue, Dec 12, 2017 at 7:25 AM, Corey Floyd cfloyd@wikimedia.org wrote:
Just a reminder that this is happening this Thursday. Please update any tools you have before then. Thanks!
On Fri, Dec 1, 2017 at 3:30 PM Corey Floyd cfloyd@wikimedia.org wrote:
Hi all,
The experimental Trending Service[1] will be sunset on December 14th,
We initially deployed this service to evaluate some real time features in the mobile apps centered on delivering more timely information to users. After some research [2], we found that it did not perform well with users in that use case.
At this point there are no further plans to integrate the service into
our
products and so we are going to sunset the service to reduce the maintenance burden for some of our teams.
We are going to do this more quickly than we would for a full stable production API as the usage of the end point is extremely low and mostly from our own internal projects. If you this adversely affects any of your work or you have any other concerns, please let the myself or the Reading Infrastructure team know.
Thanks to all the teams involved with developing, deploying, researching and maintaining this service.
P.S. This service was based off of prototypes Jon Robson had developed
for
detecting trending articles. He will be continuing his work in this
area. I
encourage you to reach out to him if you were interested in this project.
[1] https://en.wikipedia.org/api/rest_v1/#!/Feed/trendingEdits [2] https://meta.wikimedia.org/wiki/Research:Comparing_most_
read_and_trending_edits_for_Top_Articles_feature
-- Corey Floyd Engineering Manager Readers Wikimedia Foundation cfloyd@wikimedia.org
-- Corey Floyd Engineering Manager Readers Wikimedia Foundation cfloyd@wikimedia.org _______________________________________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
(Volunteer hat on)
I'm a little sad we didn't find a place for this in the Wikipedia apps or web products, but I plan to maintain a labs instance going forward: https://wikipedia-trending.wmflabs.org/ And a web presentation with a push notification feature (which notified be this morning of the death of Ed Lee https://trending.wmflabs.org/en.wikipedia/Ed%20Lee%20(politician)): https://trending.wmflabs.org/
This is a little inferior to the production version as it is unable to use production kafka and if it has any outages it will lose data.
I'm hoping to get this onto IFTTT https://ifttt.com/wikipedia with help from Stephen Laporte in my volunteer time, as I think this feature is a pretty powerful one which has failed to find its use case in the wiki world. As Kaldari points out it's incredibly good at detecting edit wars and I personally have learned a lot about what our editors see as important and notable in the world (our editors really seem to like wrestling). I think there are ample and exciting things people could build on top of this api.
The gadget script is crude (as there is no way to install a service worker via a user script) but will continue to work if you want to try it (but Firefox only) - I just updated it to use the new endpoint.
I will continue to explore trending's place in the Wikimedia universe :)
On Tue, 12 Dec 2017 at 10:43 Ryan Kaldari rkaldari@wikimedia.org wrote:
One interesting thing that I noticed about the trending edits API is that it was fairly useful in identifying articles that were under attack by vandals or experiencing an edit war. A lot of times a vandal will just sit on an article and keep reverting back to the vandalized version until an admin shows up, which can sometimes take a while. If you tweak the parameters passed to the API, you can almost get it to show nothing but edit wars (high number of edits, low number of editors).
This makes me think that this API is actually useful, it's just targeted to the wrong use case. If we built something similar, but that just looked for high numbers of revert/undos (rather than edits), and combined it with something like Jon Robson's trending edits user script ( https://en.wikipedia.org/wiki/User:Jdlrobson/Gadget-trending-edits.js), we could create a really powerful tool for Wikipedia administrators to identify problems without having to wait for them to be reported at AN/I or AIV.
On Tue, Dec 12, 2017 at 7:25 AM, Corey Floyd cfloyd@wikimedia.org wrote:
Just a reminder that this is happening this Thursday. Please update any tools you have before then. Thanks!
On Fri, Dec 1, 2017 at 3:30 PM Corey Floyd cfloyd@wikimedia.org wrote:
Hi all,
The experimental Trending Service[1] will be sunset on December 14th,
We initially deployed this service to evaluate some real time features
in
the mobile apps centered on delivering more timely information to
users.
After some research [2], we found that it did not perform well with
users
in that use case.
At this point there are no further plans to integrate the service into
our
products and so we are going to sunset the service to reduce the maintenance burden for some of our teams.
We are going to do this more quickly than we would for a full stable production API as the usage of the end point is extremely low and
mostly
from our own internal projects. If you this adversely affects any of
your
work or you have any other concerns, please let the myself or the
Reading
Infrastructure team know.
Thanks to all the teams involved with developing, deploying,
researching
and maintaining this service.
P.S. This service was based off of prototypes Jon Robson had developed
for
detecting trending articles. He will be continuing his work in this
area. I
encourage you to reach out to him if you were interested in this
project.
[1] https://en.wikipedia.org/api/rest_v1/#!/Feed/trendingEdits [2] https://meta.wikimedia.org/wiki/Research:Comparing_most_
read_and_trending_edits_for_Top_Articles_feature
-- Corey Floyd Engineering Manager Readers Wikimedia Foundation cfloyd@wikimedia.org
-- Corey Floyd Engineering Manager Readers Wikimedia Foundation cfloyd@wikimedia.org _______________________________________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
FWIW, I did the research comparing Trending edits to top pageviews, and I *also* think Trending edits is a promising tool and am glad to hear that it going forward in some fashion even if it's being pulled from production (for now?). I hope we can continue to develop the model, and I'm confident that we will find valuable use cases for it.
- J
On Tue, Dec 12, 2017 at 12:12 PM, Jon Robson jdlrobson@gmail.com wrote:
(Volunteer hat on)
I'm a little sad we didn't find a place for this in the Wikipedia apps or web products, but I plan to maintain a labs instance going forward: https://wikipedia-trending.wmflabs.org/ And a web presentation with a push notification feature (which notified be this morning of the death of Ed Lee https://trending.wmflabs.org/en.wikipedia/Ed%20Lee%20(politician)): https://trending.wmflabs.org/
This is a little inferior to the production version as it is unable to use production kafka and if it has any outages it will lose data.
I'm hoping to get this onto IFTTT https://ifttt.com/wikipedia with help from Stephen Laporte in my volunteer time, as I think this feature is a pretty powerful one which has failed to find its use case in the wiki world. As Kaldari points out it's incredibly good at detecting edit wars and I personally have learned a lot about what our editors see as important and notable in the world (our editors really seem to like wrestling). I think there are ample and exciting things people could build on top of this api.
The gadget script is crude (as there is no way to install a service worker via a user script) but will continue to work if you want to try it (but Firefox only) - I just updated it to use the new endpoint.
I will continue to explore trending's place in the Wikimedia universe :)
On Tue, 12 Dec 2017 at 10:43 Ryan Kaldari rkaldari@wikimedia.org wrote:
One interesting thing that I noticed about the trending edits API is that it was fairly useful in identifying articles that were under attack by vandals or experiencing an edit war. A lot of times a vandal will just
sit
on an article and keep reverting back to the vandalized version until an admin shows up, which can sometimes take a while. If you tweak the parameters passed to the API, you can almost get it to show nothing but edit wars (high number of edits, low number of editors).
This makes me think that this API is actually useful, it's just targeted
to
the wrong use case. If we built something similar, but that just looked
for
high numbers of revert/undos (rather than edits), and combined it with something like Jon Robson's trending edits user script ( https://en.wikipedia.org/wiki/User:Jdlrobson/Gadget-trending-edits.js),
we
could create a really powerful tool for Wikipedia administrators to identify problems without having to wait for them to be reported at AN/I
or
AIV.
On Tue, Dec 12, 2017 at 7:25 AM, Corey Floyd cfloyd@wikimedia.org
wrote:
Just a reminder that this is happening this Thursday. Please update any tools you have before then. Thanks!
On Fri, Dec 1, 2017 at 3:30 PM Corey Floyd cfloyd@wikimedia.org
wrote:
Hi all,
The experimental Trending Service[1] will be sunset on December 14th,
We initially deployed this service to evaluate some real time
features
in
the mobile apps centered on delivering more timely information to
users.
After some research [2], we found that it did not perform well with
users
in that use case.
At this point there are no further plans to integrate the service
into
our
products and so we are going to sunset the service to reduce the maintenance burden for some of our teams.
We are going to do this more quickly than we would for a full stable production API as the usage of the end point is extremely low and
mostly
from our own internal projects. If you this adversely affects any of
your
work or you have any other concerns, please let the myself or the
Reading
Infrastructure team know.
Thanks to all the teams involved with developing, deploying,
researching
and maintaining this service.
P.S. This service was based off of prototypes Jon Robson had
developed
for
detecting trending articles. He will be continuing his work in this
area. I
encourage you to reach out to him if you were interested in this
project.
[1] https://en.wikipedia.org/api/rest_v1/#!/Feed/trendingEdits [2] https://meta.wikimedia.org/wiki/Research:Comparing_most_
read_and_trending_edits_for_Top_Articles_feature
-- Corey Floyd Engineering Manager Readers Wikimedia Foundation cfloyd@wikimedia.org
-- Corey Floyd Engineering Manager Readers Wikimedia Foundation cfloyd@wikimedia.org _______________________________________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Admin assistance is definitely an interesting use case… there is also the possibility of including incorporating ORES scores to see what changes are actually good or not.
Since the API is primarily based off of edits, it isn’t too surprising that a contributor / admin use case may be a better fit here. So the Trending may yet have another life as a tool for administrators. It is definitely something to test out to see if it is useful…
As Jon said, the Cloud VPS version may not be as reliable as Kafka, but hopefully it is enough to evaluate this type of use… and maybe, as others have mentioned, a good reason to get production Kafka events flowing into Cloud VPS backed projects.
On Tue, Dec 12, 2017 at 3:27 PM Jonathan Morgan jmorgan@wikimedia.org wrote:
FWIW, I did the research comparing Trending edits to top pageviews, and I *also* think Trending edits is a promising tool and am glad to hear that it going forward in some fashion even if it's being pulled from production (for now?). I hope we can continue to develop the model, and I'm confident that we will find valuable use cases for it.
- J
On Tue, Dec 12, 2017 at 12:12 PM, Jon Robson jdlrobson@gmail.com wrote:
(Volunteer hat on)
I'm a little sad we didn't find a place for this in the Wikipedia apps or web products, but I plan to maintain a labs instance going forward: https://wikipedia-trending.wmflabs.org/ And a web presentation with a push notification feature (which notified be this morning of the death of Ed Lee https://trending.wmflabs.org/en.wikipedia/Ed%20Lee%20(politician)): https://trending.wmflabs.org/
This is a little inferior to the production version as it is unable to use production kafka and if it has any outages it will lose data.
I'm hoping to get this onto IFTTT https://ifttt.com/wikipedia with help from Stephen Laporte in my volunteer time, as I think this feature is a pretty powerful one which has failed to find its use case in the wiki world. As Kaldari points out it's incredibly good at detecting edit wars and I personally have learned a lot about what our editors see as important and notable in the world (our editors really seem to like wrestling). I think there are ample and exciting things people could build on top of this api.
The gadget script is crude (as there is no way to install a service worker via a user script) but will continue to work if you want to try it (but Firefox only) - I just updated it to use the new endpoint.
I will continue to explore trending's place in the Wikimedia universe :)
On Tue, 12 Dec 2017 at 10:43 Ryan Kaldari rkaldari@wikimedia.org wrote:
One interesting thing that I noticed about the trending edits API is
that
it was fairly useful in identifying articles that were under attack by vandals or experiencing an edit war. A lot of times a vandal will just
sit
on an article and keep reverting back to the vandalized version until an admin shows up, which can sometimes take a while. If you tweak the parameters passed to the API, you can almost get it to show nothing but edit wars (high number of edits, low number of editors).
This makes me think that this API is actually useful, it's just
targeted to
the wrong use case. If we built something similar, but that just looked
for
high numbers of revert/undos (rather than edits), and combined it with something like Jon Robson's trending edits user script ( https://en.wikipedia.org/wiki/User:Jdlrobson/Gadget-trending-edits.js),
we
could create a really powerful tool for Wikipedia administrators to identify problems without having to wait for them to be reported at
AN/I or
AIV.
On Tue, Dec 12, 2017 at 7:25 AM, Corey Floyd cfloyd@wikimedia.org
wrote:
Just a reminder that this is happening this Thursday. Please update
any
tools you have before then. Thanks!
On Fri, Dec 1, 2017 at 3:30 PM Corey Floyd cfloyd@wikimedia.org
wrote:
Hi all,
The experimental Trending Service[1] will be sunset on December
14th,
We initially deployed this service to evaluate some real time
features
in
the mobile apps centered on delivering more timely information to
users.
After some research [2], we found that it did not perform well with
users
in that use case.
At this point there are no further plans to integrate the service
into
our
products and so we are going to sunset the service to reduce the maintenance burden for some of our teams.
We are going to do this more quickly than we would for a full stable production API as the usage of the end point is extremely low and
mostly
from our own internal projects. If you this adversely affects any of
your
work or you have any other concerns, please let the myself or the
Reading
Infrastructure team know.
Thanks to all the teams involved with developing, deploying,
researching
and maintaining this service.
P.S. This service was based off of prototypes Jon Robson had
developed
for
detecting trending articles. He will be continuing his work in this
area. I
encourage you to reach out to him if you were interested in this
project.
[1] https://en.wikipedia.org/api/rest_v1/#!/Feed/trendingEdits [2] https://meta.wikimedia.org/wiki/Research:Comparing_most_
read_and_trending_edits_for_Top_Articles_feature
-- Corey Floyd Engineering Manager Readers Wikimedia Foundation cfloyd@wikimedia.org
-- Corey Floyd Engineering Manager Readers Wikimedia Foundation cfloyd@wikimedia.org _______________________________________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
-- Jonathan T. Morgan Senior Design Researcher Wikimedia Foundation User:Jmorgan (WMF) https://meta.wikimedia.org/wiki/User:Jmorgan_(WMF)
ri-team mailing list ri-team@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/ri-team
On Tue, Dec 12, 2017 at 12:12 PM, Jon Robson jdlrobson@gmail.com wrote:
This is a little inferior to the production version as it is unable to use production kafka and if it has any outages it will lose data.
Hopefully that gets fixed soon, Cloud VPS / Toolforge is the foundation for out volunteer tool developer community who really shouldn't be treated as second-class citizens.
Other than that, moving to the Cloud is not a bad thing for an experimental project IMO. It makes it easier to experiment with minimal risk, and it makes it easy to add co-collaborators to your project without having to get prod access for them.
I'm hoping to get this onto IFTTT https://ifttt.com/wikipedia with help
from Stephen Laporte in my volunteer time, as I think this feature is a pretty powerful one which has failed to find its use case in the wiki world. As Kaldari points out it's incredibly good at detecting edit wars and I personally have learned a lot about what our editors see as important and notable in the world (our editors really seem to like wrestling). I think there are ample and exciting things people could build on top of this api.
Yeah a "give me push notifications about ongoing edit wars" tool for admins sounds really cool. Although you'd probably want to look at revert trends (or both edit and revert trends) for that.
This is a little inferior to the production version as it is unable to use
production kafka and if it has any outages it will lose data.
EventStreams isn’t as good as using Kafka, but an outage shouldn’t be a reason to lose data. Store the Last-Event-ID https://wikitech.wikimedia.org/wiki/EventStreams#Format that EventStreams gives you, and you can use it when the service starts back up to start from where you left off.
> and maybe, as others have mentioned, a good reason to get production Kafka events flowing into Cloud VPS backed projects.
Def not opposed to a Kafka cluster in Cloud mirroring from Prod. :)
BTW, this is a wee relevant: https://wikitech.wikimedia.org/wiki/User:Ottomata/Stream_Data_Platform
This is a draft! I’m shopping this around as a program for next FY. We will see!
On Tue, Dec 12, 2017 at 4:16 PM, Gergo Tisza gtisza@wikimedia.org wrote:
On Tue, Dec 12, 2017 at 12:12 PM, Jon Robson jdlrobson@gmail.com wrote:
This is a little inferior to the production version as it is unable to
use
production kafka and if it has any outages it will lose data.
Hopefully that gets fixed soon, Cloud VPS / Toolforge is the foundation for out volunteer tool developer community who really shouldn't be treated as second-class citizens.
Other than that, moving to the Cloud is not a bad thing for an experimental project IMO. It makes it easier to experiment with minimal risk, and it makes it easy to add co-collaborators to your project without having to get prod access for them.
I'm hoping to get this onto IFTTT https://ifttt.com/wikipedia with help
from Stephen Laporte in my volunteer time, as I think this feature is a pretty powerful one which has failed to find its use case in the wiki world. As Kaldari points out it's incredibly good at detecting edit wars and I personally have learned a lot about what our editors see as
important
and notable in the world (our editors really seem to like wrestling). I think there are ample and exciting things people could build on top of
this
api.
Yeah a "give me push notifications about ongoing edit wars" tool for admins sounds really cool. Although you'd probably want to look at revert trends (or both edit and revert trends) for that. _______________________________________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Since there is some confusion on the thread, I would like to clarify that I am using EventStreams in the labs version. There is no way too use Kafka outside production and no way to replay historical events (which was what made this so much better in production).
(code for this is mostly in *https://github.com/jdlrobson/wikitrender/blob/master/index.js https://github.com/jdlrobson/wikitrender/blob/master/index.js *for those interested)
On Tue, 12 Dec 2017 at 13:33 Andrew Otto otto@wikimedia.org wrote:
This is a little inferior to the production version as it is unable to
use production kafka and if it has any outages it will lose data.
EventStreams isn’t as good as using Kafka, but an outage shouldn’t be a reason to lose data. Store the Last-Event-ID https://wikitech.wikimedia.org/wiki/EventStreams#Format that EventStreams gives you, and you can use it when the service starts back up to start from where you left off.
> and maybe, as others have mentioned, a good reason to get production Kafka events flowing into Cloud VPS backed projects.
Def not opposed to a Kafka cluster in Cloud mirroring from Prod. :)
BTW, this is a wee relevant: https://wikitech.wikimedia.org/wiki/User:Ottomata/Stream_Data_Platform
This is a draft! I’m shopping this around as a program for next FY. We will see!
On Tue, Dec 12, 2017 at 4:16 PM, Gergo Tisza gtisza@wikimedia.org wrote:
On Tue, Dec 12, 2017 at 12:12 PM, Jon Robson jdlrobson@gmail.com
wrote:
This is a little inferior to the production version as it is unable to
use
production kafka and if it has any outages it will lose data.
Hopefully that gets fixed soon, Cloud VPS / Toolforge is the foundation
for
out volunteer tool developer community who really shouldn't be treated as second-class citizens.
Other than that, moving to the Cloud is not a bad thing for an
experimental
project IMO. It makes it easier to experiment with minimal risk, and it makes it easy to add co-collaborators to your project without having to
get
prod access for them.
I'm hoping to get this onto IFTTT https://ifttt.com/wikipedia with
help
from Stephen Laporte in my volunteer time, as I think this feature is a pretty powerful one which has failed to find its use case in the wiki world. As Kaldari points out it's incredibly good at detecting edit
wars
and I personally have learned a lot about what our editors see as
important
and notable in the world (our editors really seem to like wrestling). I think there are ample and exciting things people could build on top of
this
api.
Yeah a "give me push notifications about ongoing edit wars" tool for
admins
sounds really cool. Although you'd probably want to look at revert trends (or both edit and revert trends) for that. _______________________________________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
It's an incredibly useful tool for people outside of our existing community — who use Wikipedia to determine what's resonating worldwide. I've tweeted about it several times and it always gets pickup from journalists:
https://twitter.com/mkramer/status/940676642636206091
Happy to put you in touch if you ever want to do user research interviews.
On Tue, Dec 12, 2017 at 3:12 PM, Jon Robson jdlrobson@gmail.com wrote:
(Volunteer hat on)
I'm a little sad we didn't find a place for this in the Wikipedia apps or web products, but I plan to maintain a labs instance going forward: https://wikipedia-trending.wmflabs.org/ And a web presentation with a push notification feature (which notified be this morning of the death of Ed Lee https://trending.wmflabs.org/en.wikipedia/Ed%20Lee%20(politician)): https://trending.wmflabs.org/
This is a little inferior to the production version as it is unable to use production kafka and if it has any outages it will lose data.
I'm hoping to get this onto IFTTT https://ifttt.com/wikipedia with help from Stephen Laporte in my volunteer time, as I think this feature is a pretty powerful one which has failed to find its use case in the wiki world. As Kaldari points out it's incredibly good at detecting edit wars and I personally have learned a lot about what our editors see as important and notable in the world (our editors really seem to like wrestling). I think there are ample and exciting things people could build on top of this api.
The gadget script is crude (as there is no way to install a service worker via a user script) but will continue to work if you want to try it (but Firefox only) - I just updated it to use the new endpoint.
I will continue to explore trending's place in the Wikimedia universe :)
On Tue, 12 Dec 2017 at 10:43 Ryan Kaldari rkaldari@wikimedia.org wrote:
One interesting thing that I noticed about the trending edits API is that it was fairly useful in identifying articles that were under attack by vandals or experiencing an edit war. A lot of times a vandal will just
sit
on an article and keep reverting back to the vandalized version until an admin shows up, which can sometimes take a while. If you tweak the parameters passed to the API, you can almost get it to show nothing but edit wars (high number of edits, low number of editors).
This makes me think that this API is actually useful, it's just targeted
to
the wrong use case. If we built something similar, but that just looked
for
high numbers of revert/undos (rather than edits), and combined it with something like Jon Robson's trending edits user script ( https://en.wikipedia.org/wiki/User:Jdlrobson/Gadget-trending-edits.js),
we
could create a really powerful tool for Wikipedia administrators to identify problems without having to wait for them to be reported at AN/I
or
AIV.
On Tue, Dec 12, 2017 at 7:25 AM, Corey Floyd cfloyd@wikimedia.org
wrote:
Just a reminder that this is happening this Thursday. Please update any tools you have before then. Thanks!
On Fri, Dec 1, 2017 at 3:30 PM Corey Floyd cfloyd@wikimedia.org
wrote:
Hi all,
The experimental Trending Service[1] will be sunset on December 14th,
We initially deployed this service to evaluate some real time
features
in
the mobile apps centered on delivering more timely information to
users.
After some research [2], we found that it did not perform well with
users
in that use case.
At this point there are no further plans to integrate the service
into
our
products and so we are going to sunset the service to reduce the maintenance burden for some of our teams.
We are going to do this more quickly than we would for a full stable production API as the usage of the end point is extremely low and
mostly
from our own internal projects. If you this adversely affects any of
your
work or you have any other concerns, please let the myself or the
Reading
Infrastructure team know.
Thanks to all the teams involved with developing, deploying,
researching
and maintaining this service.
P.S. This service was based off of prototypes Jon Robson had
developed
for
detecting trending articles. He will be continuing his work in this
area. I
encourage you to reach out to him if you were interested in this
project.
[1] https://en.wikipedia.org/api/rest_v1/#!/Feed/trendingEdits [2] https://meta.wikimedia.org/wiki/Research:Comparing_most_
read_and_trending_edits_for_Top_Articles_feature
-- Corey Floyd Engineering Manager Readers Wikimedia Foundation cfloyd@wikimedia.org
-- Corey Floyd Engineering Manager Readers Wikimedia Foundation cfloyd@wikimedia.org _______________________________________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Hello all,
Just a quick note to let you know that as of now the trending edits public end point is no longer available to clients.
On a personal note, I also concur that such a tool is an interesting source of data that can be applied in various contexts and hope to see work picked up in the future.
Cheers,
Marko Obrovac, PhD Senior Services Engineer Wikimedia Foundation
On 12 December 2017 at 22:56, Melody Kramer mkramer@wikimedia.org wrote:
It's an incredibly useful tool for people outside of our existing community — who use Wikipedia to determine what's resonating worldwide. I've tweeted about it several times and it always gets pickup from journalists:
https://twitter.com/mkramer/status/940676642636206091
Happy to put you in touch if you ever want to do user research interviews.
On Tue, Dec 12, 2017 at 3:12 PM, Jon Robson jdlrobson@gmail.com wrote:
(Volunteer hat on)
I'm a little sad we didn't find a place for this in the Wikipedia apps or web products, but I plan to maintain a labs instance going forward: https://wikipedia-trending.wmflabs.org/ And a web presentation with a push notification feature (which notified
be
this morning of the death of Ed Lee https://trending.wmflabs.org/en.wikipedia/Ed%20Lee%20(politician)): https://trending.wmflabs.org/
This is a little inferior to the production version as it is unable to
use
production kafka and if it has any outages it will lose data.
I'm hoping to get this onto IFTTT https://ifttt.com/wikipedia with
help
from Stephen Laporte in my volunteer time, as I think this feature is a pretty powerful one which has failed to find its use case in the wiki world. As Kaldari points out it's incredibly good at detecting edit wars and I personally have learned a lot about what our editors see as
important
and notable in the world (our editors really seem to like wrestling). I think there are ample and exciting things people could build on top of
this
api.
The gadget script is crude (as there is no way to install a service
worker
via a user script) but will continue to work if you want to try it (but Firefox only) - I just updated it to use the new endpoint.
I will continue to explore trending's place in the Wikimedia universe :)
On Tue, 12 Dec 2017 at 10:43 Ryan Kaldari rkaldari@wikimedia.org
wrote:
One interesting thing that I noticed about the trending edits API is
that
it was fairly useful in identifying articles that were under attack by vandals or experiencing an edit war. A lot of times a vandal will just
sit
on an article and keep reverting back to the vandalized version until
an
admin shows up, which can sometimes take a while. If you tweak the parameters passed to the API, you can almost get it to show nothing but edit wars (high number of edits, low number of editors).
This makes me think that this API is actually useful, it's just
targeted
to
the wrong use case. If we built something similar, but that just looked
for
high numbers of revert/undos (rather than edits), and combined it with something like Jon Robson's trending edits user script ( https://en.wikipedia.org/wiki/User:Jdlrobson/Gadget-trending-edits.js
),
we
could create a really powerful tool for Wikipedia administrators to identify problems without having to wait for them to be reported at
AN/I
or
AIV.
On Tue, Dec 12, 2017 at 7:25 AM, Corey Floyd cfloyd@wikimedia.org
wrote:
Just a reminder that this is happening this Thursday. Please update
any
tools you have before then. Thanks!
On Fri, Dec 1, 2017 at 3:30 PM Corey Floyd cfloyd@wikimedia.org
wrote:
Hi all,
The experimental Trending Service[1] will be sunset on December
14th,
We initially deployed this service to evaluate some real time
features
in
the mobile apps centered on delivering more timely information to
users.
After some research [2], we found that it did not perform well with
users
in that use case.
At this point there are no further plans to integrate the service
into
our
products and so we are going to sunset the service to reduce the maintenance burden for some of our teams.
We are going to do this more quickly than we would for a full
stable
production API as the usage of the end point is extremely low and
mostly
from our own internal projects. If you this adversely affects any
of
your
work or you have any other concerns, please let the myself or the
Reading
Infrastructure team know.
Thanks to all the teams involved with developing, deploying,
researching
and maintaining this service.
P.S. This service was based off of prototypes Jon Robson had
developed
for
detecting trending articles. He will be continuing his work in this
area. I
encourage you to reach out to him if you were interested in this
project.
[1] https://en.wikipedia.org/api/rest_v1/#!/Feed/trendingEdits [2] https://meta.wikimedia.org/wiki/Research:Comparing_most_
read_and_trending_edits_for_Top_Articles_feature
-- Corey Floyd Engineering Manager Readers Wikimedia Foundation cfloyd@wikimedia.org
-- Corey Floyd Engineering Manager Readers Wikimedia Foundation cfloyd@wikimedia.org _______________________________________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
-- Melody Kramer https://www.mediawiki.org/wiki/User:MKramer_(WMF) Senior Audience Development Manager Read a random featured article from Wikipedia! https://en.wikipedia.org/wiki/Special:RandomInCategory/Featured_articles
mkramer@wikimedia.org _______________________________________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
wikitech-l@lists.wikimedia.org