Single post in Implementing A 'Block' Feature
Forum Index > Core > Suggestions > Under Consideration > Implementing A 'Block' Feature >
Not editing this into my previous post since I want it to push a notif to anyone subbed. I'd really appreciate it if y'all took the time to read this!
As a foreword, some things I'm going to say here are going to be in response to specific users and other things will be points I'm just bringing up because they need attention. I'm not quoting those users because this post is already long enough as it is and I believe I managed to make the point well enough without needing the context of those posts. Please let me know if that's not the case and I'll figure out... something.
There seems to be a widespread assumption that this is a simple thing that can just be done. As someone who's sat in call and watched Niet code in real time, he is better at this especially in the present day than he's given due credit for. While I said don't worry too much about things like lag, there are still things we have to keep in mind, also in regards to lag itself. Don't allow "lag" to be a prohibitive point that causes you to oppose this suggestion. Just remember that the features of the site stack on top of each other, intersect at different places, and branch off in other ways. This is true of a lot of complex coding projects. It's not even really a tree anymore, it's a straight up spiderweb simply due to the extent of it, where different parts rejoin and branch off again somewhere else down the line. Now, in terms of adding a block feature to this spiderweb, it's like adding roadblocks. You find a point in the spiderweb where you're like "I want this to no longer be an option for people who are blocked," but then you have to consider the likely many ways they can get around that via other paths in the web. This ties back to something I said previously that I would like to clarify. Any process Sally does will cause some amount of "lag" in that it simply takes some measure of time in order to complete. Whether that amount of time is efficient, negligible enough to be acceptable, and/or worth it for the benefit that is gained determines whether or not it's particularly "laggy" for the server or just par for the course, even if that time is measured in fractions of a second or even fractions of a millisecond. They add up quickly and become several seconds in total, enough to be noticeable, when Sally has to do a lot of searches and cross-referencing, such as for keeping track of which part of the spiderweb you're at, whether or not there is a roadblock, and the conditions that that roadblock imposes. This is in addition to everything Sally already does. The main intent of staff joining in this thread and trying to help it along was to request specific assistance in figuring out the conditions the roadblocks should have, trying to find a compromise between the "hard block where the blocked person(s) don't exist in my user experience at all" ideal and the reality of the situation where Sally can't take that amount of stress and we have to aim for a "soft block where the blocked person(s) still exist but where certain restrictions are imposed." There's also still ongoing evaluation on whether or not this is at all possible given what PFQ is and whether or not this is a feature that would have to be put exclusively on "PFNew" (affectionate nickname). If at all, mind. We're trying to meet with you guys somewhere in the middle but we want help finding where that point is. To that end, I'd like to request that we refocus on the suggestion itself and especially in answering Niet's concerns in his two posts starting here. I understand that some discussion has occurred on these points, but ultimately this is where the focus is further needed. If you understand the concerns Niet posed here, what are your own ideas for solutions to it? Given that a block is not a report, then either blocks need to be accompanied by a report through the block function itself or via the usual reporting process. This has basically been established, and the mock-up for this looked pretty nice. There's some questions, though. At what points should the initial block be allowed to go through fully automated and at what points should the block require Moderator attention? Should Moderators have to fully review every block request as we review and act on reports or approve Clans to ensure people aren't being nasty, or should we only review for certain reasons/causes? Are you opposed to the suggestion entirely for reasons not yet stated? If so, why? You do actually already have the autonomy and power to "block" users if you wish. You can use the features of browsers such as Google Chrome in order to "block" users by preventing the page from loading if it is a specific URL, such as a specific user page or specific PM conversation. This would not block the user on multi-profile or click lists, and the other user would still be visible in the forums, but this option is available to anyone who seeks these specific options. I'd also like to point on that blocking someone actually doesn't do really anything to de-escalate the situation (except perhaps in cases where that is your only point of contact), and in fact often serves to exacerbate the issue by allowing it to move off-site. This isn't victim-blaming, mind, it's just the truth about how some particularly nasty folks on the receiving end of a block may choose to act. It's also the reason why we would prefer, for example, child predator concerns be reported as early as possible - it's less so "it's your fault if they move on to harass someone else," and more so "we would prefer to stop this as soon as possible so that doing this to someone else is not an option that the offender has." We want there to be less victims of child predators, harassment, bullying, thefts, and so on, so we request that you report any concerning instances immediately. It has been noted that DNI for "Do Not Interact" seems to be a popular acronym in this thread and I've seen it on Trainer Cards in the recent past, but I would like to firmly request everyone discontinue the use of this acronym and instead use DNC for "Do Not Contact." As a Moderator who has had to enforce DNCs and had to tell people that I cannot enforce DNIs, I'll explain why. Due to the in-game mechanic of clicking being called "making interactions" and the fact there is an entire page of the site called the Interactions page (or "Today's Interactions" if you go by the header of the page), the concept of DNI itself becomes unclear. Are you asking for them not to contact you in any way (PMs, trade threads, etc.), or are you just asking them not to click your Pokemon? Given that Site Rule 2A says that people can click however they want
I'll leave the thread locked while I sleep tonight to give folks time to read this so it doesn't get flooded out, and then I'll unlock the thread in the morning.
Edit: Apologies for the late unlock; today got a bit hectic. Please feel free to continue the discussion. Be kind to each other. 🙂
There seems to be a widespread assumption that this is a simple thing that can just be done. As someone who's sat in call and watched Niet code in real time, he is better at this especially in the present day than he's given due credit for. While I said don't worry too much about things like lag, there are still things we have to keep in mind, also in regards to lag itself. Don't allow "lag" to be a prohibitive point that causes you to oppose this suggestion. Just remember that the features of the site stack on top of each other, intersect at different places, and branch off in other ways. This is true of a lot of complex coding projects. It's not even really a tree anymore, it's a straight up spiderweb simply due to the extent of it, where different parts rejoin and branch off again somewhere else down the line. Now, in terms of adding a block feature to this spiderweb, it's like adding roadblocks. You find a point in the spiderweb where you're like "I want this to no longer be an option for people who are blocked," but then you have to consider the likely many ways they can get around that via other paths in the web. This ties back to something I said previously that I would like to clarify. Any process Sally does will cause some amount of "lag" in that it simply takes some measure of time in order to complete. Whether that amount of time is efficient, negligible enough to be acceptable, and/or worth it for the benefit that is gained determines whether or not it's particularly "laggy" for the server or just par for the course, even if that time is measured in fractions of a second or even fractions of a millisecond. They add up quickly and become several seconds in total, enough to be noticeable, when Sally has to do a lot of searches and cross-referencing, such as for keeping track of which part of the spiderweb you're at, whether or not there is a roadblock, and the conditions that that roadblock imposes. This is in addition to everything Sally already does. The main intent of staff joining in this thread and trying to help it along was to request specific assistance in figuring out the conditions the roadblocks should have, trying to find a compromise between the "hard block where the blocked person(s) don't exist in my user experience at all" ideal and the reality of the situation where Sally can't take that amount of stress and we have to aim for a "soft block where the blocked person(s) still exist but where certain restrictions are imposed." There's also still ongoing evaluation on whether or not this is at all possible given what PFQ is and whether or not this is a feature that would have to be put exclusively on "PFNew" (affectionate nickname). If at all, mind. We're trying to meet with you guys somewhere in the middle but we want help finding where that point is. To that end, I'd like to request that we refocus on the suggestion itself and especially in answering Niet's concerns in his two posts starting here. I understand that some discussion has occurred on these points, but ultimately this is where the focus is further needed. If you understand the concerns Niet posed here, what are your own ideas for solutions to it? Given that a block is not a report, then either blocks need to be accompanied by a report through the block function itself or via the usual reporting process. This has basically been established, and the mock-up for this looked pretty nice. There's some questions, though. At what points should the initial block be allowed to go through fully automated and at what points should the block require Moderator attention? Should Moderators have to fully review every block request as we review and act on reports or approve Clans to ensure people aren't being nasty, or should we only review for certain reasons/causes? Are you opposed to the suggestion entirely for reasons not yet stated? If so, why? You do actually already have the autonomy and power to "block" users if you wish. You can use the features of browsers such as Google Chrome in order to "block" users by preventing the page from loading if it is a specific URL, such as a specific user page or specific PM conversation. This would not block the user on multi-profile or click lists, and the other user would still be visible in the forums, but this option is available to anyone who seeks these specific options. I'd also like to point on that blocking someone actually doesn't do really anything to de-escalate the situation (except perhaps in cases where that is your only point of contact), and in fact often serves to exacerbate the issue by allowing it to move off-site. This isn't victim-blaming, mind, it's just the truth about how some particularly nasty folks on the receiving end of a block may choose to act. It's also the reason why we would prefer, for example, child predator concerns be reported as early as possible - it's less so "it's your fault if they move on to harass someone else," and more so "we would prefer to stop this as soon as possible so that doing this to someone else is not an option that the offender has." We want there to be less victims of child predators, harassment, bullying, thefts, and so on, so we request that you report any concerning instances immediately. It has been noted that DNI for "Do Not Interact" seems to be a popular acronym in this thread and I've seen it on Trainer Cards in the recent past, but I would like to firmly request everyone discontinue the use of this acronym and instead use DNC for "Do Not Contact." As a Moderator who has had to enforce DNCs and had to tell people that I cannot enforce DNIs, I'll explain why. Due to the in-game mechanic of clicking being called "making interactions" and the fact there is an entire page of the site called the Interactions page (or "Today's Interactions" if you go by the header of the page), the concept of DNI itself becomes unclear. Are you asking for them not to contact you in any way (PMs, trade threads, etc.), or are you just asking them not to click your Pokemon? Given that Site Rule 2A says that people can click however they want
I cannot, as a Moderator, enforce that someone not click you. You can ask that they not do so. They simply aren't obligated per the rules to comply.
and due to the unclearness of DNI as a concept for the aforementioned reason, I cannot enforce a DNI given that not everyone will understand this caveat. I know it seems a bit pedantic but please, please say DNC instead. As an addendum to this, non-personal DNCs such as in TCs are unenforceable because there's no guarantee someone will see it - please use the PM function to make Do Not Contact requests. Remember to keep them polite.
Moving on from that, someone brought up the laws on discrimination. To clarify on these laws, in both in America as well as in the UK, you cannot deny service based on discriminatory reasons (race, sex, sexual orientation, religion or beliefs even including political beliefseg. you can't bar them because they're a conservative, liberal, democrat, tory, etc.
, etc.). If you have a non-discriminatory reason, you can deny service. If you wish to deny service and provide no reasoning for it, you can do so. However, if your reason comes to light and it's discriminatory, you can be sued and held liable in the UK.
Anyone remember the gay Colorado couple who just wanted to order a cake and got refused service? That's illegal in Colorado, much like it would have been illegal if it had happened in the UK. We operate fairly similarly on PFQ since we go by UK law - it's not exactly the same though. You can refuse service in your Trade Shops and threads to whomever you like and for whatever reason you like, just keep the reasoning to yourself or at least address it respectfully in private. DNCs aren't much different. You can request that someone never contact you again in any way and not provide a reason. They are obligated to comply, else they face consequences per the rules on general respect (Rule 2B). Anyone breaking a DNC should be reported - the only response you should ever receive to a DNC is the other person's acknowledgement that they see and/or accept it. Nothing else.
for Market equiv. 
sig code and sig bg image made by me