On 01/10/2013 01:36 PM, Ryan Kaldari wrote:
I'm fine with either of these choices, but we have to actually reach some kind of consensus on this.
From where I'm standing, I think there should be sane defaults, but each
notification type should be separately configurable.
If not, you risk people turning everything off, or worse, using the wiki less.
Matt Flaschen
Agreed with Matt. I wasn't involved in the discussions referenced, I think, but my opinion is that you cannot simply give people a boolean option on this kind of thing. "firehose of sewage or nothing" means a lot of people are going to go for "nothing", at which point we've sort of undermined the entire system.
On 10 January 2013 20:19, Matthew Flaschen mflaschen@wikimedia.org wrote:
On 01/10/2013 01:36 PM, Ryan Kaldari wrote:
I'm fine with either of these choices, but we have to actually reach some kind of consensus on this.
From where I'm standing, I think there should be sane defaults, but each notification type should be separately configurable.
If not, you risk people turning everything off, or worse, using the wiki less.
Matt Flaschen
EE mailing list EE@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/ee
I agree with Matt and Oliver as well.
I don't think we can avoid giving people individual control of which notifications they receive.
But I definitely think that adding a dismiss option in the flyout is an effective way to give people that control, so they don't have to go to the preferences page if they don't want to.
I also think that bundling can help in a number of ways, as outlined in my feature list below (I am including the entire thread, to make sure nobody feels left out from that discussion)
I will create a feature requirement stub for both options (and a few more) in coming days, and we can prioritize them as a team in next week's planning session.
But this discussion is touching upon the central challenge for this product: how to make sure that we inform people without spamming them.
It will take us a while to completely solve this challenge, but we should not ship anything that doesn't have some good solutions to this difficult problem, IMHO.
Cheers,
Fabrice
On Jan 10, 2013, at 12:30 PM, Oliver Keyes wrote:
Agreed with Matt. I wasn't involved in the discussions referenced, I think, but my opinion is that you cannot simply give people a boolean option on this kind of thing. "firehose of sewage or nothing" means a lot of people are going to go for "nothing", at which point we've sort of undermined the entire system.
On 10 January 2013 20:19, Matthew Flaschen mflaschen@wikimedia.org wrote: On 01/10/2013 01:36 PM, Ryan Kaldari wrote:
I'm fine with either of these choices, but we have to actually reach some kind of consensus on this.
From where I'm standing, I think there should be sane defaults, but each notification type should be separately configurable.
If not, you risk people turning everything off, or worse, using the wiki less.
Matt Flaschen
On Jan 10, 2013, at 10:40 AM, Ryan Kaldari wrote:
Yes, bundling will be on a per notification basis, i.e. some notifications will be bundlable and some probably won't.
Ryan Kaldari
On 1/9/13 1:35 PM, Oliver Keyes wrote:
Great :). Any thoughts on distinguishing bundle-worthy/individual-worthy types of alert?
On 9 January 2013 21:32, Fabrice Florin fflorin@wikimedia.org wrote: Hi guys,
Just wanted to let you know that Benny and Kaldari just deployed a first fix to this page link feature, to make sure that it restricts it only to 'content namespace' on MediaWiki.
For example, this notification will no longer be sent if someone puts a page link on a talkpage.
We'll keep making improvements on this and related features in coming weeks, as outlined below.
In the meantime, if someone really dislikes this feature, you can turn off email notifications for it on your preference page:
http://www.mediawiki.org/wiki/Special:Preferences#mw-prefsection-echo
Cheers,
-f
P.S.: Matthew and Oliver's recommendation to create a separate 'your page was moved' notification is duly noted and will be added to the wishlist. Keep in mind that right now we are focusing on building core features for new users, so it's likely this would take place later this year, not right away.
On Jan 9, 2013, at 10:58 AM, Fabrice Florin wrote:
Thank you all for these great comments and suggestions!
They will be very helpful for our next steps, not just for the page link feature, but for the other core features we're planning right now.
Here is a quick summary of what I think are new features to consider:
- Restrict the definition of a page link
We would only focus on article namespace links, and remove talkpage links or other page links that could create spam. We would also remove any redirects or page moves from that definition. Some of these things could be done partially today (e.g. exclude talkpage links), if we can get a deployment window.
- Make email notifications opt-in for experienced users
By default, we would uncheck the preferences box for page links, so that experienced users are not flooded with more information than they want. So if you have more than 100? edits, that preference would be disabled until you choose to enable it.
- Keep email notifications enabled for new users
This feature is actually quite valuable for new users, so they can find out what is happening with their new page. So we would check the box for anyone that has less than 100? edits, so they can benefit from this feature. I have to say that for myself, it is one of the most useful notification I have found on MediaWiki, since I rarely get talk page messages or have my edit reverted, even though I'm very active (I understand this would be different on a more active Wiki).
- Bundle email notifications
As Luke points out, spammy emails is one of the biggest risk we are facing with this project, and it is much better to send too few notifications rather than too many. So we should look for bundling solutions that allow us to either:
- stop sending emails after you've reached your daily limit (which could be a preference: 'don't send me more than 5 emails a day'); or
- only send 1 email every 4? hours or something like that (which could also be a preference: 'only send me 1 email every 4 hours')); or
- send a 'digest' email after you have received x notifications per day (e.g.: '15 people linked pages you created today. See all your notifications')
Intelligent bundling is perhaps one of the greatest design challenges for this project, and I recommend that we all focus our energy to tackling this problem in coming weeks.
- Flyout dismiss
We definitely want to add a way to dismiss notifications by type in the flyout. We had planned to do this in the second release, but could accelerate this if need be. I still think bundling is a higher priority. This will also be a tricky one to implement, because matching the user intent may prove hairy.
Thanks again for all your great feedback and creative ideas, which are music to my ears!
To be continued,
Fabrice
On Jan 9, 2013, at 10:25 AM, Luke Welling WMF wrote:
Erik's point "But it's definitely too spammy to turn it on for established users by default." is key.
We need to be very careful about turning on any email notifications for existing users. It's something that a significant number of people are very touchy about, and annoys everybody if sent in high volume.
I don't like magic thresholds where the system behaviour changes without user interaction. People expect computers to behave predictably. If you sent me an email every 2 days to say something had happened to my article then stopped, I'd assume that my article was no longer being linked to, not that I'd crossed over x edits and now need to enable the preference manually. If we really want to go that way, you need to tell people it happened, and how to undo it.
I think the best approach with email is to enable it for new users, so they see the place is alive, but only suggest to existing users that they turn it on, even if "suggesting" means as a one off sending them a sample of what this week's digest would look like for them.
Even for new users we should have cadence controls in place before we launch on busier wikis. Nobody wants 10+ emails a day. Best practice is one immediate one, then bundle up subsequent ones for a few hours, but if that is too much work for V1, only trying to send every x hours and risking delaying the first one by x hours is a better compromise than risking sending 100 mails a day.
Luke
On Jan 9, 2013, at 10:22 AM, Oliver Keyes wrote:
It turns out it currently sends you a notification when a page is moved, because that creates a redirect aimed at it. oy.
On 9 January 2013 11:35, Oliver Keyes okeyes@wikimedia.org wrote:
On 9 January 2013 06:47, Steven Walling swalling@wikimedia.org wrote: On Tue, Jan 8, 2013 at 10:35 PM, Erik Moeller erik@wikimedia.org wrote: I do get these too a fair bit from mediawiki.org, about 5-10 a day. I actually kinda like them, but I'm an information junkie.
To clarify here: I like the onsite notification, I just don't like the email. The notification feels like serendipitous information discovery, where I get to learn something I couldn't otherwise. The email feels like work, probably because I can more easily ignore a notification in the flyout.
On the "easy to disable" front, I'm not sure if this is on the roadmap already, but having an inline way to dismiss notifications of a certain type would IMO be nice, e.g. a simple "Disable this type of alert" link within the actual notification itself.
Great idea! Giving people an immediate touch point means they feel like they have control, like swatting a fly.
This would be awesome. I can't imagine the backlash if we deploy the feature as it's currently written on enwiki.
On Jan 9, 2013, at 3:35 AM, Oliver Keyes wrote:
On 9 January 2013 06:47, Steven Walling swalling@wikimedia.org wrote: On Tue, Jan 8, 2013 at 10:35 PM, Erik Moeller erik@wikimedia.org wrote: I do get these too a fair bit from mediawiki.org, about 5-10 a day. I actually kinda like them, but I'm an information junkie.
To clarify here: I like the onsite notification, I just don't like the email. The notification feels like serendipitous information discovery, where I get to learn something I couldn't otherwise. The email feels like work, probably because I can more easily ignore a notification in the flyout.
On the "easy to disable" front, I'm not sure if this is on the roadmap already, but having an inline way to dismiss notifications of a certain type would IMO be nice, e.g. a simple "Disable this type of alert" link within the actual notification itself.
Great idea! Giving people an immediate touch point means they feel like they have control, like swatting a fly.
This would be awesome. I can't imagine the backlash if we deploy the feature as it's currently written on enwiki.
On Jan 8, 2013, at 10:47 PM, Steven Walling wrote:
On Tue, Jan 8, 2013 at 10:35 PM, Erik Moeller erik@wikimedia.org wrote: I do get these too a fair bit from mediawiki.org, about 5-10 a day. I actually kinda like them, but I'm an information junkie.
To clarify here: I like the onsite notification, I just don't like the email. The notification feels like serendipitous information discovery, where I get to learn something I couldn't otherwise. The email feels like work, probably because I can more easily ignore a notification in the flyout.
On the "easy to disable" front, I'm not sure if this is on the roadmap already, but having an inline way to dismiss notifications of a certain type would IMO be nice, e.g. a simple "Disable this type of alert" link within the actual notification itself.
Great idea! Giving people an immediate touch point means they feel like they have control, like swatting a fly.
-- Steven Walling https://wikimediafoundation.org/
On Jan 8, 2013, at 10:35 PM, Erik Moeller wrote:
On Tue, Jan 8, 2013 at 3:15 PM, Vibha Bamba vbamba@wikimedia.org wrote:
if we were to define thresholds > only notify when its been linked to 10 other articles and switch this on for users with under x edits only?
I think it'd need to be restricted to new users, and also limited to links from within the article namespace (otherwise you get too much meta-crud). Beyond that, if it's easy to disable, I think it could be a nice way to surface activity and "aliveness" to new users. But it's definitely too spammy to turn it on for established users by default. Thresholds might make things too complicated though.
I do get these too a fair bit from mediawiki.org, about 5-10 a day. I actually kinda like them, but I'm an information junkie.
On the "easy to disable" front, I'm not sure if this is on the roadmap already, but having an inline way to dismiss notifications of a certain type would IMO be nice, e.g. a simple "Disable this type of alert" link within the actual notification itself.
Erik
Erik Möller VP of Engineering and Product Development, Wikimedia Foundation
On Jan 8, 2013, at 3:15 PM, Vibha Bamba wrote:
Would this notification make sense: if we were to define thresholds > only notify when its been linked to 10 other articles and switch this on for users with under x edits only?
On Tue, Jan 8, 2013 at 2:54 PM, Steven Walling swalling@wikimedia.org wrote: I have gotten four emails about this cross-linking notification this morning alone. Too much noise.
---------- Forwarded message ---------- From: MediaWiki Mail wiki@wikimedia.org Date: Tue, Jan 8, 2013 at 2:53 PM Subject: A page you started was cross referenced on MediaWiki To: Steven swalling@wikimedia.org
Onboarding new Wikipedians was linked by MediaWiki user Superm401, from this page: Guided tours
View more:
http://www.mediawiki.org/wiki/Guided_tours
To control which e-mails we send you, visit: http://www.mediawiki.org/wiki/Special:Preferences#mw-prefsection-echo
Wikimedia Foundation, 149 New Montgomery St., 3rd Fl., San Francisco, CA 94105.
On Thu, Jan 10, 2013 at 1:33 PM, Fabrice Florin fflorin@wikimedia.orgwrote:
I agree with Matt and Oliver as well.
I don't think we can avoid giving people individual control of which notifications they receive.
But I definitely think that adding a dismiss option in the flyout is an effective way to give people that control, so they don't have to go to the preferences page if they don't want to.
I also think that bundling can help in a number of ways, as outlined in my feature list below (I am including the entire thread, to make sure nobody feels left out from that discussion)
I will create a feature requirement stub for both options (and a few more) in coming days, and we can prioritize them as a team in next week's planning session.
But this discussion is touching upon the central challenge for this product: how to make sure that we inform people without spamming them.
It will take us a while to completely solve this challenge, but we should not ship anything that doesn't have some good solutions to this difficult problem, IMHO.
Cheers,
Fabrice
Just wanted to say that I am glad my grouchy email has led to this product conversation. Thanks for taking this issue of noise so seriously everyone.
On 01/10/2013 04:33 PM, Fabrice Florin wrote:
I agree with Matt and Oliver as well.
I don't think we can avoid giving people individual control of which notifications they receive.
But I definitely think that adding a dismiss option in the flyout is an effective way to give people that control, so they don't have to go to the preferences page if they don't want to.
I agree. Not just, "dismiss this one", but "Don't show this type of notification again" right on the notification itself (not necessarily those phrasings).
But this discussion is touching upon the central challenge for this product: how to make sure that we inform people without spamming them.
Right, this is critical, and the balance is different for each person (hence sane defaults with configurability).
Matt Flaschen
On Jan 10, 2013, at 1:46 PM, Matthew Flaschen mflaschen@wikimedia.org wrote:
I agree. Not just, "dismiss this one", but "Don't show this type of notification again" right on the notification itself (not necessarily those phrasings).
Hover over the notification and there's an "(x)" that appears on the right side. Click that and it dismisses the notification but also asks "Do you want to hide all notifications of this kind?" [y/n control] - if "n/cancel", dismiss/hide current element, do nothing else. - if "y" set "hide this type" preference for the user. show message about "you can set your preferences [[here]]"
--- Brandon Harris, Senior Designer, Wikimedia Foundation
Support Free Knowledge: http://wikimediafoundation.org/wiki/Donate
Thanks, Brandon!
That's pretty much what I was thinking of.
Facebook has a really nice design along those lines, which I think we can emulate.
See these screenshots in our best practices deck.
To be continued,
Fabrice
On Jan 10, 2013, at 1:50 PM, Brandon Harris wrote:
On Jan 10, 2013, at 1:46 PM, Matthew Flaschen mflaschen@wikimedia.org wrote:
I agree. Not just, "dismiss this one", but "Don't show this type of notification again" right on the notification itself (not necessarily those phrasings).
Hover over the notification and there's an "(x)" that appears on the right side. Click that and it dismisses the notification but also asks "Do you want to hide all notifications of this kind?" [y/n control] - if "n/cancel", dismiss/hide current element, do nothing else. - if "y" set "hide this type" preference for the user. show message about "you can set your preferences [[here]]"
Brandon Harris, Senior Designer, Wikimedia Foundation
Support Free Knowledge: http://wikimediafoundation.org/wiki/Donate
EE mailing list EE@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/ee
_______________________________
Fabrice Florin Product Manager Wikimedia Foundation
Donate to keep Wikipedia free: https://donate.wikimedia.org/
Facebook has a really nice design along those lines, which I think we can emulate.
See these screenshotshttps://docs.google.com/a/wikimedia.org/presentation/d/1ZRqi7bo8W-HgzJ_riskqFMTIPBIlWDmwMURbmnvr19w/edit#slide=id.g2ee45dc7_1_58 in our best practices deck.
I am starting to think that the "<page> was linked" should not be subject to individual notifications at all. In the Facebook example, and in Twitter, etc., individual notifications are sent only in the cases of human-to-human contact: someone left a comment, or followed you, or re-posted your post.
Pages you created in the past being linked by others are a different kind of interaction that is not human-to-human, but more akin to, for example, someone visiting a blog page that you wrote some time in the past. For example, I've had 149 page views on my blog today, and if I got an email for every one of those, I would be complaining. I don't even have all that many pages on mw.o, but I'm still getting a dozen emails a day roughly so far. (Note that blogger does send email when someone leaves a comment on a blog post: again, direct human contact is the trigger.)
I think it might make more sense to treat "<page> was linked" actions the way blogger treats page views. Keep a count over time of how many times each page gets linked, but don't push a message out for activity that is not direct human contact.
On 01/10/2013 05:30 PM, Chris McMahon wrote:
Facebook has a really nice design along those lines, which I think we can emulate. See these screenshots <https://docs.google.com/a/wikimedia.org/presentation/d/1ZRqi7bo8W-HgzJ_riskqFMTIPBIlWDmwMURbmnvr19w/edit#slide=id.g2ee45dc7_1_58> in our best practices deck.I am starting to think that the "<page> was linked" should not be subject to individual notifications at all.
I thought about this, and at first I thought I agreed. But I actually think it could be interesting for main namespace pages I created, especially recent ones. If it's mainspace->mainspace (a link *on* an article *to* an article) and there is a time-based filter ("links to articles you created within the last 30 days"), I would probably use it.
Pages you created in the past being linked by others are a different kind of interaction that is not human-to-human, but more akin to, for example, someone visiting a blog page that you wrote some time in the past.
I'd say it's somewhere in between, since writing something (the link is just one aspect) using your page is different from just visiting it.
Matt Flaschen
I guess that by "bundling" you refer to present several notifications of the same type as a single element. I think that aggregating them by type is something really good for certain kind of notifications, but other content-related notifications may benefit from being aggregated by content.
Thats especially relevant when several individual events are correlated or can be interpreted as signs of a more global event (which is somewhat related to the concerns raised by Chris).
For example, if a page receives 1k reads, 20 comments and 2 cross-link, it may be useful to present that as a single "Your page on Higgs Boson is becoming popular (1k reads, 20 comments and linked by 2 other pages today)".
More than a specific solution I wanted to make sure that different kinds of aggregation critera are considered when the "bundling" discussion happens.
Pau
On Thu, Jan 10, 2013 at 11:50 PM, Matthew Flaschen mflaschen@wikimedia.orgwrote:
On 01/10/2013 05:30 PM, Chris McMahon wrote:
Facebook has a really nice design along those lines, which I think we can emulate. See these screenshots <https://docs.google.com/a/wikimedia.org/presentation/d/1ZRqi7bo8W-HgzJ_riskq... in
our best practices deck.I am starting to think that the "<page> was linked" should not be subject to individual notifications at all.
I thought about this, and at first I thought I agreed. But I actually think it could be interesting for main namespace pages I created, especially recent ones. If it's mainspace->mainspace (a link *on* an article *to* an article) and there is a time-based filter ("links to articles you created within the last 30 days"), I would probably use it.
Pages you created in the past being linked by others are a different kind of interaction that is not human-to-human, but more akin to, for example, someone visiting a blog page that you wrote some time in the past.
I'd say it's somewhere in between, since writing something (the link is just one aspect) using your page is different from just visiting it.
Matt Flaschen
EE mailing list EE@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/ee
Sure; I also meant bundling the emails, however. Something in class1 should be delayed for...say, 4 hours, to see if anything else in class1 turns up. If it does, send them all in one email. If it doesn't, send whatever you've got. Something in class2 gets sent instantly.
On 11 January 2013 11:57, Pau Giner pginer@wikimedia.org wrote:
I guess that by "bundling" you refer to present several notifications of the same type as a single element. I think that aggregating them by type is something really good for certain kind of notifications, but other content-related notifications may benefit from being aggregated by content.
Thats especially relevant when several individual events are correlated or can be interpreted as signs of a more global event (which is somewhat related to the concerns raised by Chris).
For example, if a page receives 1k reads, 20 comments and 2 cross-link, it may be useful to present that as a single "Your page on Higgs Boson is becoming popular (1k reads, 20 comments and linked by 2 other pages today)".
More than a specific solution I wanted to make sure that different kinds of aggregation critera are considered when the "bundling" discussion happens.
Pau
On Thu, Jan 10, 2013 at 11:50 PM, Matthew Flaschen < mflaschen@wikimedia.org> wrote:
On 01/10/2013 05:30 PM, Chris McMahon wrote:
Facebook has a really nice design along those lines, which I think we can emulate. See these screenshots <https://docs.google.com/a/wikimedia.org/presentation/d/1ZRqi7bo8W-HgzJ_riskq... in
our best practices deck.I am starting to think that the "<page> was linked" should not be subject to individual notifications at all.
I thought about this, and at first I thought I agreed. But I actually think it could be interesting for main namespace pages I created, especially recent ones. If it's mainspace->mainspace (a link *on* an article *to* an article) and there is a time-based filter ("links to articles you created within the last 30 days"), I would probably use it.
Pages you created in the past being linked by others are a different kind of interaction that is not human-to-human, but more akin to, for example, someone visiting a blog page that you wrote some time in the past.
I'd say it's somewhere in between, since writing something (the link is just one aspect) using your page is different from just visiting it.
Matt Flaschen
EE mailing list EE@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/ee
-- Pau Giner Interaction Designer Wikimedia Foundation
EE mailing list EE@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/ee
I've heard the "a page you created in the last 30 days was linked to" idea from a couple of people so let me put in my vote against.
I really dislike complicated, mysterious behaviour. If the logic can't cleanly be described in the text description of the notification, then I think it's the wrong logic. I don't think any notification type wants a day limit filter, or a for users with <x edits filter, or any other logic that will be confusing to recipients.
The cure for spam is to not auto enable email notifications for existing accounts, and to put work into email cadence controls across all notification types (except talk page messages) before launching to "real" users. Applying weird custom business logic to different notification types is a recipe for bugs and confusion and will just lead to more weird single case cures when you hit power users who still hit their personal spam threshold on 30 day limited pages.
Simple consistent behaviour is better for the users and better for the codebase.
Luke
On Thu, Jan 10, 2013 at 2:50 PM, Matthew Flaschen mflaschen@wikimedia.orgwrote:
On 01/10/2013 05:30 PM, Chris McMahon wrote:
Facebook has a really nice design along those lines, which I think we can emulate. See these screenshots <https://docs.google.com/a/wikimedia.org/presentation/d/1ZRqi7bo8W-HgzJ_riskq... in
our best practices deck.I am starting to think that the "<page> was linked" should not be subject to individual notifications at all.
I thought about this, and at first I thought I agreed. But I actually think it could be interesting for main namespace pages I created, especially recent ones. If it's mainspace->mainspace (a link *on* an article *to* an article) and there is a time-based filter ("links to articles you created within the last 30 days"), I would probably use it.
Pages you created in the past being linked by others are a different kind of interaction that is not human-to-human, but more akin to, for example, someone visiting a blog page that you wrote some time in the past.
I'd say it's somewhere in between, since writing something (the link is just one aspect) using your page is different from just visiting it.
Matt Flaschen
EE mailing list EE@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/ee
I was sort of assuming this was a foregone conclusion and been focusing on mitigation, but if we're cool with me showing up late to the party, I'm with Luke on this. The concept of "being linked to" in a Wikipedian sense is not massively transparent to new users. It also isn't necessarily particularly meaningful.
On 11 January 2013 19:19, Luke Welling WMF lwelling@wikimedia.org wrote:
I've heard the "a page you created in the last 30 days was linked to" idea from a couple of people so let me put in my vote against.
I really dislike complicated, mysterious behaviour. If the logic can't cleanly be described in the text description of the notification, then I think it's the wrong logic. I don't think any notification type wants a day limit filter, or a for users with <x edits filter, or any other logic that will be confusing to recipients.
The cure for spam is to not auto enable email notifications for existing accounts, and to put work into email cadence controls across all notification types (except talk page messages) before launching to "real" users. Applying weird custom business logic to different notification types is a recipe for bugs and confusion and will just lead to more weird single case cures when you hit power users who still hit their personal spam threshold on 30 day limited pages.
Simple consistent behaviour is better for the users and better for the codebase.
Luke
On Thu, Jan 10, 2013 at 2:50 PM, Matthew Flaschen <mflaschen@wikimedia.org
wrote:
On 01/10/2013 05:30 PM, Chris McMahon wrote:
Facebook has a really nice design along those lines, which I think we can emulate. See these screenshots <https://docs.google.com/a/wikimedia.org/presentation/d/1ZRqi7bo8W-HgzJ_riskq... in
our best practices deck.I am starting to think that the "<page> was linked" should not be subject to individual notifications at all.
I thought about this, and at first I thought I agreed. But I actually think it could be interesting for main namespace pages I created, especially recent ones. If it's mainspace->mainspace (a link *on* an article *to* an article) and there is a time-based filter ("links to articles you created within the last 30 days"), I would probably use it.
Pages you created in the past being linked by others are a different kind of interaction that is not human-to-human, but more akin to, for example, someone visiting a blog page that you wrote some time in the past.
I'd say it's somewhere in between, since writing something (the link is just one aspect) using your page is different from just visiting it.
Matt Flaschen
EE mailing list EE@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/ee
EE mailing list EE@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/ee
